What changed

An operator who grades a drafted story reads the result in plain language, never the bare internal name "gate-1"

This change delivers the following acceptance criteria:

• AC1: (integration) Given an operator approves a drafted story so Flow grades it before admitting it to the run, When they read the result — whether the story is admitted or sent back for revision — Then the readiness-grading step and the next step are described in plain language (such as "the readiness review") and the bare term "gate-1" never appears in what they read.
• AC2: Given an operator's drafted story does not pass grading, When they read the message telling them it was sent back for revision, Then it explains in plain language that the readiness review did not pass and what to do next, without using the bare term "gate-1".
• AC3: Given the readiness-grading step is described to the operator in the approve/grade flow and in any docs that explain it, When an operator reads any of those surfaces, Then the step is named with plain, consistent wording while the five-judge review and the Quality Lead decision behave exactly as before.

Why

As a non-engineer operator approving a drafted story, I want to read the grading result and any send-back guidance in plain language, instead of the opaque internal codename "gate-1", so that I understand what just happened to my story and what to do next, without having to learn an internal term I have no way to decode.

How to check it yourself

Run /flow:ready against a drafted story — the log output and verdict messages now say 'the readiness review' instead of 'gate-1'. On escalate (any lens fails), the operator sees: 'the readiness review did not pass — revise the draft and re-run /flow:ready to grade it again.' On bless, the log says 'the draft cleared all five lenses' (unchanged, already plain). Search gate-1.workflow.js for bare 'gate-1' strings in log() or agent() calls — only the internal meta.name and phase label remain.

Risk and blast radius

Risk tier: medium

The change is scoped to the files in the diff below. Review the diff to judge its actual blast radius — including any effect on shared state, data schemas, or authentication paths — before approving.

What is explicitly not covered: reviewer verification of this summary's accuracy is handled by a separate companion story.

Evidence

The pre-pull-request build-and-test gate passed before this pull request was opened. No pull request can be opened by the automated flow unless both pnpm build and pnpm test exit 0 in the developer's working directory.

Per-criterion covering checks:

• AC1 → verify at plugins/flow/workflows/internal/gate-1.workflow.js (not an automated test)
• AC2 → verify at plugins/flow/workflows/internal/gate-1.workflow.js (not an automated test)
• AC3 → verify at plugins/flow/skills/ready/SKILL.md (not an automated test)

Story: native:01KVVGC2A2ARH4QNC6GCQNK9G8
Spec: .flow/native-stories/01KVVGC2A2ARH4QNC6GCQNK9G8.md
ACs:

• AC1: (integration) Given an operator approves a drafted story so Flow grades it before admitting it to the run, When they read the result — whether the story is admitted or sent back for revision — Then the readiness-grading step and the next step are described in plain language (such as "the readiness review") and the bare term "gate-1" never appears in what they read.
• AC2: Given an operator's drafted story does not pass grading, When they read the message telling them it was sent back for revision, Then it explains in plain language that the readiness review did not pass and what to do next, without using the bare term "gate-1".
• AC3: Given the readiness-grading step is described to the operator in the approve/grade flow and in any docs that explain it, When an operator reads any of those surfaces, Then the step is named with plain, consistent wording while the five-judge review and the Quality Lead decision behave exactly as before.

Replace gate-1 codename with plain-language readiness review in all operator-facing surfaces